Producer/Project Management - It Never Ends

This project was a master`s module job [Game Craft] for the University of Plymouth, England. In this module, we had to form groups and create a game from the scratch. My role was the producer. Below, can be founded what was done by me as a producer in the game.

gama management game game producer Game Production management producer

I`ve explained what are, in a very short summary, the responsibilities of a Producer in a game project.

The sources of "what do a producer in games". The book is the may source and it is very good! The sites was a summary of what a producer does and they helped me to remember what I`ve read on the book [I've read it a some year ago and it has more than pages. But it was a amazing reading].

Having meetings is essential to get the project in course and ensure it was finished. I like presential meetings, but online meetings count. The important is get the team reunited, make follow-ups, set deadlines, claim results and so on.

As part of a good management, have an official platform to make the daily communication is essential. There the team can read over the project, having questions solved, report status and so on. We did a Discord Channel so we could divide into productions area and be more assertive about the communication.

This was a milestone and a general chronogram I made on Excel. First, I have set the milestones for levels, since our game was a small one, and put some test and polishing in order to have a better and beautiful game. One thing that I added before was the deliveries of each milestone. That is VERY important, because the team has to know what is expected from them after each part of the production.

As platform used to the project management, I’ve decided to use the Microsoft Planner because the university have the Microsoft Office 365. In this scenario, was easy for us student to use it because we already have accounts in this system, avoiding to create a whole new account in another system.

As the producer, I was incubated to leader the meetings. So, in order to make them more productive, I developed this simple framework for the meetings. With it, everybody already know the meeting subject and what to bring to it.

Also, after every reunion, I made the meeting record, shared with everyone in the team. I made in order to have a record for the meeting itself and in case to someone forget about what was spoken and what are the next steps, they could go on the meeting record and be updated.

Constant follow-up is part of the daily life of a producer. It avoid to have the project always on the trails and, when we start to see the things are getting wrong we can act immediately according to our chronogram and resources.

Part of the job as a producer is to try to identify problems, not only when they appear but also, and mainly, and there are chances that the problems happen. So, every time we see something can be wrong or could happen, we have to be in touch with the team, make them aware of the problems/concerning and try to mitigate it as soon as possible. Also, as possible as we can, we should try to propose solutions for solve problems or to avoid them to happen.

One of the mains things to remember is that, as producer, we do not have to concern about the game design itself. In general, we are supposed to ensure the final delivery of the game in time, with quality and accordingly to the client’s desire. And, having this in mind, we claim for results to the production team to ensure that. If the design/art/mechanics are ok for the client and we have time and other resources, that’s ok. We only ask for changes to the production team if we see something which goes against final deadline and/or client desire.

I´ve led the team, trying my best to be attached to the chronogram and try to solve problems.

I’ve helped the game designer to do the technical part of the designer [just because I have experience on this]. This avoided the information to be more organized and as complete as possible.

This is a simple Power Point with the mains parts involved with the mechanics of the game. This helped the game designer to remember the main part of the mechanic and register it so the coder and the artist [or anyone else involved] to know what to do in thar part specifically.

The milestone and the chronogram help the team to know the deadlines and expected deliveries. So we all are able to make efforts in that particular part to bring the project to life.

I`ve read all documentation about the project and made many questions to the game designer. I missed that information and these missing pieces were delaying the project, either for the others do not know what to do/how to do or generating rework to the team because a task was made differently from what was expected.

As I as struggling to understand the world in the game, I started to identify ever piece of work we should have, as mechanic, animation, sound etc. So, with this, I was able have a map of the project and, with this, I was able to make the Planner correctly, allowing me to better view our project progress.

Also, knowing every piece that our game should have, I was able to do a map for the items and enemies in the game. So, now the level designer could know where the first appearance of something should be, when they should appear again and when they do not. Also was kind of a map for what our artist should focus, as well our coder.

As result of all the maps above, I was able to do a nice Planner, getting the columns separated by level [they were very short]. And, inside every column, a specific card about the asset involved, very specific. Inside each card, there was the name of the responsible, deadlines, explanation/check lists/associated files and two kinds of tags: one for the Production Area and another for the Level of the game. This all made for better filtering when necessary [for better follow-up].

The files organization is something crucial in a project. Not only the folders but the files as a register of the technical information and their names as well.